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AN  ASSESSMENT  OF  THE  ABILITY  OF  MAINTENANCE  AND  LOGISTIC 
MODELS  TO  SUPPORT  RESEARCH  ON  EARLY  ESTIMATION 


INTRODUCTION 


One  goal  o£  the  MANPRINT  program  is  to  develop  methods  and  techni¬ 
ques  to  assist  in  designing  supportable  materiel  systems.  The  abili¬ 
ties  and  characteristics  of  the  maintenance  function  supporting  a 
materiel  system  are  acknowledged  to  be  a  key  issue  in  system  support- 
ability.  Therefore,  the  ability  to  optimize  the  characteristics  of  the 
maintenance  function  can  function  as  both  a  force  multiplier  (by 
supporting  higher  levels  of  readiness  and  sustainability)  and  in 
minimizing  life  cycle  costs. 

The  Army  Research  Institute  (ARI)  supports  the  MANPRINT  program  by 
developing  tools  and  methods  that  can  be  used  to  extrapolate  the 
consequences  of  materiel  and  support  system  designs  upon  manpower, 
personnel,  and  training  (MPT)  demands  once  a  system  is  fielded. 
Maintenance  has  been  identified  as  a  significant  consumer  of  MPT 
resources,  and  is  receiving  attention  as  part  of  this  process.  One 
goal  of  work  in  this  area  is  to  find  ways  to  reduce  skill  demands  in 
the  maintenance  workforce,  as  well  as  the  overall  maintenance  burden. 

A  conceptual  model  of  factors  influencing  the  Army  maintenance 
function  has  been  developed  (Evans  and  Roth,  1988).  This  model 
identifies  approximately  50  variables  and  factors  (see  Table  1)  that 
can  contribute  to  the  performance  of  maintenance  and  the  MPT  demands  of 
the  maintenance  function.  For  convenience,  these  variables  are 
segregated  by  acquisition  versus  operations  issues,  in  four  major 
domains:  policy,  MPT,  system  design,  and  logistics  (an  extensive 

discussion  of  the  variables  is  provided  in  Evans  and  Roth,  1988). 

Future  work  may  explore  the  discrete  and  joint  influences  of  these 
factors,  to  develop  methods  for  maintenance  optimization. 

It  is  infeasible  to  design  and  implement  alternative  maintenance 
functions  on  an  experimental  basis  to  develop  optimization  methods. 

This  approach  would  have  a  low  likelihood  of  acceptance,  and  very  high 
cost  implications.  An  alternate  approach  is  to  develop  or  adapt,  and 
exercise,  models  that  reflect  important  characteristics  of  maintenance 
functions.  Models  of  this  general  type  exist  and  are  used  for  logistic 
and  maintenance  estimation  by  the  military  services  (DoD,  1987). 

The  goal  of  this  effort  was  to  identify  candidate  models  or 
estimation  approaches,  and  evaluate  their  potential  use  as  tools  to 
explore  means  of  optimizing  maintenance.  This  required  the  conceptual 
model  referred  to  above,  since  it  was  necessary  to  know  which  variables 
might  need  to  be  accommodated  by  modeling  approaches  under  evaluation. 
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Table  1 


Maintenance  Demand  Factors  Model 


Type  of  Issue 

System  Life  Cycle  Issues 

Policy  Issues 

Acquisition 

Issues 

Operatic 

nal  Issues 

Levels  of  Repair 

Allocation  of  Tasks 

Maintenance  Concept 

Maintenance  Strategy 

Maintenance 

Perspective 

Force  Structure  (TOE) 

O&O  Plan 

Potential 

Compensatory 

Factors 

Givens 

Promotion  Flow 

Extended  Storage 
of  Equipment 

1 

Distractors 

OPTEMPO 

MPT  Issues 

1 

Planned  Manpower 

Training 

Personnel  KSAs 

Force  Structure  (TOE) 

Personnel  Mix 

Publications 

Actual  Manpower 

Actual  Personnel 
KSAs 

Training 

Motivation 

Diagnosis 

TMDE  Use 

Management  & 
Supervision 

Formal  Training 

OJT 

Tool  Control 

Preventive 

Maintenance 

Retention 

Publications  Use 

System  Operation 

System  Status 
Reporting 

Crew  Preventive 
Maintenance 

Migration  into 

CMF 
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Table  1  (Concluded) 


Maintenance  Demand  Factors  Model 


Type  of  Issue 

System  Life  Cycle  Issues 

Design  Issues 

Acquisition 

Issues 

Operatio 

nal  Issues 

Maintainability 

Design 

Automatic  Fault 
Diagnostics 
(BIT, BITE, ATE) 

Parts  Commonality 

Planned  RAM 

Acquisition  Strategy 

Testibility  Design 

Potential 

Come  snsatory 
Factors 

Givens 

Achieved  RAM 

Logistics 

Issues 

Facilities 

Publications 

Spare  Parts  and 

Expendables 

Provisioning 

Tool  Control 

1 - 

Spare  Parts 
Availability 
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METHODS 


This  effort  was  carried  out  in  three  sequential  steps.  The  first 
step  was  to  identify  candidate  models  for  evaluation.  This  was 
accomplished  by  examining  the  DoD  Catalog  of  Logistic  Models  (DoD, 
1987),  and  by  telephone  with  points  of  contact  in  agencies  responsible 
for  performing  maintenance  and  logistic  estimation  for  new  and  existing 
materiel  systems.  The  agencies  contacted  were: 

1.  U.S.  Army  Logistics  Center,  Fort  Lee,  Virginia. 

2.  Air  Force  Systems  Command,  Wr ight-Patterson  Air  Force  Base, 
Oh  io. 

3.  Air  Force  Human  Resources  Laboratory,  Logistics  and 
Technical  Training  Division,  Wr ight-Patterson  Air  Force 
Base,  Ohio. 

4 .  ARI . 

Also,  it  was  decided  to  examine  a  class  of  modeling  approaches  using 
tools  that  tend  to  be  more  straightforward  and  less  data-  and  resource¬ 
intensive  to  use  than  large-scale  models.  This  decision  resulted  from 
the  fact  that  logistic  estimation  models  in  general  are  very  data- 
intensive  and  usually  require  mainframe  computers  for  efficient 
execution.  Given  the  likelihood  of  limited  resources  for  future  work 
in  this  area,  it  seemed  logical  to  identify  tools  that  might  fit  more 
readily  into  resource  constraints  than  the  more  traditional  logistic 
modeling  approaches.  This  class  of  approaches  is  typified  by  models 
developed  using  a  software  product  known  as  MicroSAINT(TM) .  This  tool 
is  an  outgrowth  of  large-scale  modeling  techniques  and  shares  many  of 
the  strengths  of  such  techniques,  but  can  be  used  on  personal  com¬ 
puters.  MicroSAINT(TM)  is  essentially  a  high-level  programming 
language  developed  specifically  for  building  models. 

As  a  result  of  the  identification  effort,  more  than  200  different 
models  were  identified.  In  view  of  the  limited  resources  available  for 
the  evaluation  effort,  a  decision  was  made  to  select  no  more  than  10 
models  or  modeling  approaches  on  which  to  gather  data.  The  following 
criteria  were  used  in  selecting  approaches  and  models: 

1.  The  models  or  approaches  should  be  operational  rather  than 
developmental.  This  is  desirable,  since  an  operational 
model  will  typically  be  validated  and  debugged,  and  there 
should  be  a  reasonable  idea  of  its  flexibility  and  ability 
to  accommodate  variables  of  interest. 

2.  The  models  chosen  should  be  accepted  and  routinely  used  for 
estimation  in  the  communities  where  they  are  used.  This 
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reflects  some  confidence  in  the  predictive  validity,  as 
well  as  face  validity,  of  the  models. 

3.  The  models  should  accommodate  a  significant  proportion  of 
the  variables  and  factors  identified  as  acquisition- 
impacted  factors  in  the  Evans  and  Roth  (1988)  conceptual 
model  of  maintenance.  Single-variable  or  restricted  domain 
models  will  clearly  not  be  suitable  for  analyses  that  wish 
to  accommodate  flexible  exploration  of  the  consequences  of 
factors  and  decisions  upon  maintenance  demand. 

As  a  result  of  applying  these  criteria  to  the  initial  list  of  models,  a 
total  of  five  modeling  approaches,  used  in  logistic  or  maintenance 
estimation  during  systems  acquisition,  were  selected  for  further  study. 
These  are; 

1.  The  Logistics  Composite  Model  (LCOM) ,  developed  by  the  Air 
Force  Human  Resources  Laboratory  (AFHRL)  and  widely  used 
among  Air  Force  planners  and  logisticians. 

2.  The  Optimum  Supply  and  Maintenance  Model  (OSAMM;  Department 
of  the  Army,  1985),  developed  by  the  Army  Communications- 
Electronics  Command  (CECOM)  and  used  for  logistics  estima¬ 
tion. 

3.  The  Logistics  Analysis  Model  (LOGAM;  Department  of  the 
Army,  1984),  developed  and  used  by  the  Army  Missile  Command 
(MICOM)  for  maintenance  and  logistic  estimation. 

4.  The  MAnpower  Requirements  Criteria  (MARC)  development 
models  developed  and  used  by  the  Army  Logistics  Center 
(LOGC)  for  developing  maintenance  manning  criteria. 
Currently,  only  one  of  the  three  projected  MARC  models  (for 
aviation  systems)  is  operational  (Price,  1988),  The 
tracked  vehicle  model  is  due  to  come  on  line  within  the 
next  year,  and  a  wheeled  vehicle  model  is  under  develop¬ 
ment  . 

5.  HARDMAN  II  (formerly  MIST) — a  computerized  tool  developed 
by  ARI  to  support  manpower  and  personnel  estimation  for 
developing  materiel  systems  (Herlihy,  Iceton,  Oneal,  & 
Guptill,  1985). 

To  this  list  of  five  models  was  added  a  class  of  sma 1 ler-scale  modeling 
approaches,  exemplified  by  MicroSAINT(TM) ,  which  was  developed  under 
the  auspices  of  the  U.S.  Army  Air  Defense  Center  and  School  at  Fort 
Bliss,  and  currently  marketed  as  off-the-shelf  software.  While 
MicroSAINT(TM)  is  not  a  logistic  or  maintenance  estimation  model,  it  is 
a  model  development  approach  that  can  potentially  support  the  creation 
of  more  tractable  sorts  of  models  than  the  larger-scale  logistic 
models.  This  particular  tool  requires  only  a  modest  amount  of  computer 
capability  (it  executes  on  personal  computers),  and  is  capable  of  both 
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discrete  event  and  stochastic  modeling,  considered  in  this  effort  to  be 
a  useful  attribute. 

The  MANpower  CAPability  (MANCAP)  model  developed  by  ARI  as  part  of 
MANPRINT  efforts  for  the  Light  Helicopter  Experimental  (LHX)  program 
was  not  considered  in  this  effort,  although  it  was  originally  included 
in  the  candidate  list  of  models.  A  parallel  effort  to  define  a  more 
global,  flexible  modeling  capability  based  on  the  original  MANCAP  model 
was  being  performed  during  the  period  when  this  work  was  conducted.  It 
was  decided  that  an  additional  evaluation  of  MANCAP  would  represent  a 
duplication  of  effort.  Therefore,  MAITCAP  was  not  considered  in  the 
work  reported  here. 


Model  Characteristics  Assessment 


The  second  step  involved  obtaining  documentation  on  each  of  the 
approaches  selected  for  attention.  Study  of  the  documentation  was 
expected  to  support  the  process  of  characterizing  each  model  or 
technique  on  a  number  of  dimensions  that  are  considered  important  for 
evaluating  their  applicability  in  future  work  in  this  area.  The 
dimensions  that  were  defined  as  of  importance  are: 

1.  Input  data  requirements.  Ideally,  a  model  for  exploratory 
use  should  have  minimal  requirements  for  input  data  or  the 
development  of  descriptive  algorithms  to  model  input  data 
characteristics.  Specific  domains  of  input  data  that  are 
needed  to  prepare  for  a  model  execution  were  identified. 
These  are: 

a.  Mission  models.  Characterization  of  the  specific  or 
generic  missions  to  be  performed  by  the  type  of  unit 
being  modeled.  This  includes  mission  resources 
needed  (how  many  of  what  types  of  systems), 
frequency  of  each  type  of  mission,  expected  mission 
durations,  mission  conditions,  and  criteria  for 
conducting  missions  under  limited  resource 
conditions  (e.g.,  what  are  the  minimum  resources 
required  to  conduct  a  specific  type  of  mission). 

b.  Organization.  The  numbers  and  relationships  of 
assets  in  the  unit  or  other  organizational  structure 
that  is  being  modeled.  This  includes  unit 
identification,  association  of  equipment  with  units, 
organizational  structures,  command  and  control 
relationships,  and  other  organizational  data.  It 
may  include  some  manpower  data,  but  does  not  include 
personnel  data  (e.g.,  MOS  and  skill  levels). 

c.  Logistic  variables.  Number  and  placement  of  spare 
parts,  transport  times,  availability  and  number  of 
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maintenance  organizational  contact  teams,  various 
sorts  of  delay  time  assumptions  and  doctrine,  etc. 


d.  Manpower  and  Personnel  (M&P)  variables.  Numbers  of 
people  and  personnel  characteristics  at  each 
organizational  level  of  the  maintenance,  operations, 
and  support  functions.  Includes  distributions  and 
numbers  of  MOSs  by  skill  level  in  most  cases.  These 
variables  are  sometimes  embedded  in  task  factors 
(see  below). 

e.  Battle  damage  (BD)  factors.  The  impact  of  battle 
damage  on  systems,  including  various  sorts  of  conse¬ 
quences  of  weapons  effects  and  target  aspects. 

These  data  are  generally  supplied  by  the  Ballistic 
Research  Laboratory  when  needed. 

f.  Use.  Use  rate  factors  for  each  type  of  system;  also 
known  as  operational  tempo  factors. 

g.  Task  factors.  The  identification,  distribution 
across  maintenance  levels,  and  resource  requirements 
(manpower  and  spare  parts)  for  each  maintenance 
task.  Conditions  that  require  task  performance 
(condition  or  time)  are  also  commonly  included  in 
task  data. 

2.  Preparation  time  for  one  run  of  the  model.  Time  and  as¬ 
sociated  level  of  effort  are  scarce  resources.  Therefore, 
it  is  in  the  interest  of  future  research  involving  the  use 
of  models  to  minimize  Che  amount  of  time  needed  to  prepare 
and  format  data  to  control  model  execution. 

3.  Execution  time  for  one  run  of  the  model.  Computer  resour¬ 
ces  are  also  valuable.  Some  models  are  known  to  Cake 
between  hours  and  days  to  execute,  especially  chose  that 
must  iterate  processes  many  times.  Minimizing  the  amount 
of  time  required  to  perform  modeling  research  will  be 
benef icial . 

4.  Level  of  effort  for  model  and  data  preparation.  The  amount 
of  effort  required  to  develop  and  execute  a  model  through 
one  run,  including  all  necessary  input  data.  This  includes 
coordination  with  other  agencies  to  obtain  data.  The  level 
of  effort  ideally  should  be  as  small  as  possible. 

5.  Model  capability  for  stochastic  and  event  modeling.  Since 
there  are  no  predictive  algorithms  known  to  exist  that  link 
many  of  the  factors  in  Che  Evans  and  Roth  (1988)  conceptual 
model,  both  statistical  (stochastic)  and  event-based 
(deterministic)  representations  will  have  to  be  used  to 
simulate  Che  effects  of  such  relationships.  Therefore,  it 
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is  importanc  Chat  the  models  be  able  to  handle  both  kinds 
of  representations  of  events  or  phenomena. 

6.  Sensitivity  analysis  capability.  This  refers  to  the 
ability  to  manipulate  one  or  more  input  variables  across 
discrete  values  or  ranges  and  examine  the  related  effects 
on  output  quantities  or  variables.  This  capability  is 
important  to  developing  predictive  relationships  regarding 
the  consequences  of  various  factors  on  maintenance  demand. 

7.  Sensitivity  analysis  level  of  effort  requirements.  In  some 
cases,  many  different  variable  values  may  be  explored  in 
one  execution  through  a  model,  while  in  others,  it  may  be 
necessary  to  alter  the  input  data  sets  and  completely  re- 
execute  the  model  to  conduct  a  sensitivity  analysis.  The 
former  case  is  desirable,  since  it  minimizes  the  amount  of 
redundant  work  to  be  performed  in  using  a  model. 

8.  Ability  to  incorporate  or  manipulate  the  variables  of 
interest  from  the  Evans  and  Roth  (1988)  conceptual  model. 
The  more  variables  that  can  be  accommodated  and  later 
varied,  the  higher  the  value  of  a  model  to  future  efforts 
in  this  area. 

9.  Phenomena  coverage  (domains).  The  capability  of  a  model  to 
represent  and  manipulate  variables  pertaining  to  the  four 
major  variable  categories  in  the  Evans  and  Roth  (1988) 
conceptual  model  (policy;  MPT;  logistics;  and  system 
design).  This  was  of  interest  because  it  is  expected  that 
some  domains  (e.g.,  system  design)  may  be  more  important  in 
influencing  maintenance  demand  and  skills  than  others 
(e.g. ,  logist ics ) . 

10.  Output  data  characteristics.  This  refers  to  the  sorts  of 
data  that  are  produced  as  a  result  of  model  execution 
against  an  input  database.  These  are  in  general  categories 
(e.g.,  availability,  MPT,  etc.),  rather  than  specifics, 
since,  in  some  cases,  it  was  not  possible  to  examine  the 
output  of  a  model  execution. 

11.  Availability.  Whether  a  model  or  approach  is  Government- 
owned  and  available  for  use  by  researchers,  and  the  model's 
users  or  custodians. 

12.  Usage  cost  factors.  All  of  the  identifiable  factors  that 
may  contribute  to  the  cost  of  use  of  the  modeling  approach 
or  model. 

The  available  documentation  on  each  model  was  reviewed  to  identify  the 
range  of  each  of  the  12  characteristics  associated  with  the  model. 
Document  reviews  were  supplemented  with  interviews  with  personnel  with 
working  knowledge  of  each  approach,  when  necessary.  In  some  cases, 
gross  estimates  of  some  characteristics  were  made  based  on  implications 
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in  the  documentation  that  either  were  unsupported,  or  could  not  be 
confirmed . 


After  the  characterization  of  each  model  was  completed,  the  data 
were  tabulated  and  examined  in  the  aggregate.  This  examination  led  to 
an  overall  assessment  of  each  of  the  six  approaches  individually  to 
support  exploratory  research  into  optimizing  maintenance.  Further 
scrutiny  of  the  literature  was  supplemented  by  contact  with  developing 
organizations  and  users  for  some  of  the  modeling  approaches  that  were 
evaluated.  Comments  on  the  suitability  of  each  approach  were  added  to 
the  tabulation  of  model  characteristics.  Based  on  the  composite 
outcome  of  the  model  evaluation  process,  the  various  models  were 
roughly  rank-ordered  as  to  their  relative  suitability  for  research 
purposes.  This  does  not  imply  an  assessment  of  suitability  for  the 
primary  purposes  for  which  the  models  were  developed.  Each  of  the 
models  evaluated  is  considered  to  be  a  useful  tool  in  the  domain  for 
which  the  model  was  developed. 
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RESULTS 


The  characteristics  of  each  of  the  six  models  or  approaches  that 
were  examined  are  summarized  in  Table  2.  The  remainder  of  this  section 
contains  a  discussion  of  findings  on  each  characteristic  for  each  of 
the  six  models  or  approaches,  and  a  summary  discussion  of  the  suitabil¬ 
ity  of  the  models  for  research  purposes. 


LCOM  Characteristics 


LOOM,  developed  by  the  Air  Force  Human  Resources  Laboratory  in  the 
early  1970' s,  is  the  "grand-daddy"  of  comprehensive  maintenance 
manpower  estimation  models.  Since  the  general  functionality  of  this 
model  is  representative  of  the  way  some  of  the  other  models  (specific¬ 
ally  the  MARC  models)  operate,  a  brief  summary  is  in  order  at  this 
point.  The  basic  approach  embodied  in  LCOM  is  to  "play  out  the  war" 
from  a  logistic  perspective,  to  evaluate  the  sufficiency  of  logistic 
resources  (including  maintenance  manpower)  to  support  a  unit  in 
sustained  combat  operations.  Mission  requirements  (sorties)  and 
mission  resources  (aircraft  or  other  systems  by  type  and  combat  load) 
are  supplied  to  the  model  as  input,  as  are  the  characteristics  and 
limitations  of  logistic  and  manpower  resources  to  support  operations. 
Various  other  parameters,  such  as  battle  damage  probabilities,  munit¬ 
ions  shot  lines,  availability  of  manpower  (or  personnel)  or  spare 
parts,  etc.  are  defined,  also  as  part  of  input  data.  These  parameters 
are  defined  by  Che  LCOM  analysts,  as  part  of  input  data  development. 

The  comprehensive  input  database  controls  model  execution  during  a  run. 
The  model  run  simulates  Che  performance  of  Che  assigned  missions,  on  a 
user-specifiable  time  resolution  scale  (one  day's  resolution  is  a 
commonly  used  scale).  Losses,  battle  damage,  and  scheduled  and 
unscheduled  maintenance  Casks  are  simulated  as  part  of  the  model 
functionality.  Maintenance  resource  demands  and  consumption  are 
Cracked  as  part  of  Che  model's  output  database,  as  are  system  avail¬ 
ability,  mission  accomplishment,  numbers  of  systems  available,  and 
logistic  system  performance  (in  terms  of  supporting  maintenance  and 
sortie  capability). 

The  model  can  be  executed  over  as  many  simulated  "days"  as  desired 
by  Che  user,  to  examine  maintenance  system  performance  in  both  brief 
and  protracted  simulated  combat.  A  common  scenario  used  in  LCOM 
simulations  is  a  scenario  modeling  a  Warsaw  Pact-NATO  non-nuclear  major 
force  conflict  in  central  Europe.  Maintenance  performance  in  LCOM  is 
based  on  task  description  data,  including  tasks  to  be  performed, 
manpower  requirements,  and  spare  parts  requirements,  both  specified  by 
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Table  2 


Assessment  of  Modeling  Approaches 

MODELING  APPROACHES 

EVALUATION 

CHARACTERISTICS  LCC»i  OSAMM 


Input  Data  Require¬ 
ments 

Mission,  M&P,  BD, 
Organization,  Task 

Task,  Use,  Logistic, 
Organization,  M&P 

Preparation  Time 

Months 

Months 

Execution  Time 

Hours  (variable) 

Hours  (variable) 

Level  of  Effort  for 
Preparat ion 

Moderate 

Moderate 

Stochastic  versus 

Event  Modeling 

Both 

Both 

Sensitivity  Analysis? 

Yes 

Yes 

Level  of  Effort  for 
Sensitivity  Analysis 

Large 

Moderate 

Incorporate  Variables 
of  Interest? 

Most  variables  (not 
compensatory) 

Most,  but  not  M&P  or 
compensatory 

Phenomena  Coverage 
(Domains) 

Policy,  MPT,  logis¬ 
tics,  some  design 
(indirect ) 

Policy,  logistics, 
design  (indirect) 

Output  Data  Charac¬ 
teristics 

Availability,  M&P, 
resource  demand  and 
consumption,  events, 
input 

Maint.  policy, 
availability,  task 
distributions,  costs 
input,  manpower 

Availability 

Yes — Air  Force  (ASD) 

Yes- -Army  (CECOM) 

Cost  of  Use  Factors 

Preparation,  data, 

CPU  time,  output 
interpretation 

Preparation,  data, 
CPU  time,  output 
interpretation 

Comments 

Very  comprehensive, 
but  also  very 
resource-intensive 

Linear  optimization 
approach  (somewhat 
limiting) 
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Table  2  (Continued) 


Assessment  of  Modeling  Approaches 

MODELING  APPROACHES 

EVALUATION 


CHARACTERISTICS 

LOGAM 

Aviation  MARC 

Input  Data  Require¬ 
ments 

Logistic,  manpower, 
use,  task,  organiza- 
t  ion 

Mission,  org.  ,  use, 
BD,  M&P,  logistic 

Preparation  Time 

Months 

Months 

Execution  Time 

Minutes 

8  -  A0+  hours 

Level  of  Effort  for 
Preparation 

Moderate 

Large 

Stochastic  versus 

Event  Modeling 

Both 

Both 

Sensitivity  Analysis? 

Yes 

Yes 

Level  of  Effort  for 
Sensitivity  Analysis 

Large 

Very  Large 

Incorporate  Variables 
of  Interest? 

Some  variables  (not 
compensatory) 

Most  variables  (not 
compensatory) 

Phenomena  Coverage 
(Domains) 

Policy,  manpower, 
logistics,  some 
design  (indirect) 

Policy,  some  MPT, 
logistics,  some 
design  (indirect) 

Output  Data  Charac¬ 
teristics 

Availability,  maint. 
and  ops.  demand,  LRU 
supportability 

Availability,  events, 
resource  use, 
summaries,  input 

Avail  ability 

Yes— Army  (MICOM) 

Yes — Army  (LOGO 

Cost  of  Use  Factors 

Preparation,  data, 
output  interpretation 

Preparation,  data, 

CPU  time,  output 
interpretat ion 

Comments 

Poor  domain  coverage, 
restricted  linear 
optimization 

Very  comprehensive, 
resource  intensive, 
large  input  data 
requirements 
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Table  2  (Concluded) 


Assessment  of  Modeling  Approaches 

MODELING  APPROACHES 

EVALUATION  Reduced-scale 


CHARACTERISTICS 

HARDMAN  II 

Modeling  Approach 

Input  Data  Require¬ 
ments 

Task,  FEA  decisions, 
assumptions 

Organization, 
logistics,  use,  M&P 

Preparation  Time 

Months 

Weeks 

Execution  Time 

Highly  variable 

Hours  (uses  PC) 

Level  of  Effort  for 
Preparation 

Moderate 

Small  to  moderate 

Stochastic  versus 

Event  Modeling 

Ne ither 

Both 

Sensitivity  Analysis? 

Yes 

Yes 

Level  of  Effort  for 
Sensitivity  Analysis 

Moderate 

Small  (theoretically) 

Incorporate  Variables 
of  Interest? 

Some  (not  compen¬ 
satory) 

Potentially  most 
(including  compen¬ 
satory) 

Phenomena  Coverage 
(Domains) 

Policy,  MPT,  some 
design  (indirect)  - 
not  compensatory 

Potentially  all  (some 
probably  indirect) 

Output  Data  Charac¬ 
teristics 

M&P,  training,  FEA 
data,  input 

To  be  determined  (all 
data  of  interest) 

Availability 

Yes— ARI 

Software- -yes 

Model — not  yet 

Cost  of  Use  Factors 

Data  preparation, 

FEA,  output  inter¬ 
pretation 

Model  and  data 
preparation,  output 
interpretation 

Comments 

Not  a  modeling 
approach;  useful  for 
sensitivity  analysis 

See  text  for  discus¬ 
sion  of  this  ap- 
pr oach . 
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task.  Realistic  nonproductive  time  ratios  are  used  in  developing 
maintenance  manpower  availability.  The  capability  to  represent  task 
performance  degradation  due  to  sustained  or  continuous  operations,  or 
to  Mission  Oriented  Protective  Posture  (MOPP),  can  be  achieved  through 
manipulation  of  maintenance  task  time  estimates.  Nonproductive  time 
and  performance  degradation  parameters  can  be  based  on  analysis  of 
real-world  data,  or  can  be  simply  estimates  provided  by  analysts.  Both 
approaches  are  reported  to  have  been  used. 


LOOM  Characteristics  Summary 


The  data  below  expand  on  the  presentation  in  Table  2  with  respect 
to  characteristics  of  LOOM. 

1.  Input  data  requirements.  LOOM  requires  input  of  all 
classes  of  data  considered  as  potential  input  data  in  this 
report.  This  includes  mission  data  (required  mission  types 
and  assets);  organizational  data  (characteristics  of  the 
maintenance  organization,  including  levels  and  task 
assignments  to  levels);  logistic  data  (availability  of 
spare  parts,  logistic  delay  factors,  and  cannibalization 
rules);  maintenance  task  characteristics  data  (task 
identification,  time  distributions  by  task,  manpower 
requirements  by  task,  and  contingency  factors);  manpower 
and  personnel  data  (some  embedded  in  maintenance  task  data- 
manpower  requirements  and  assumptions  about  personnel 
characteristics  and  other  data  that  is  explicitly  provided, 
including  career  field  cross-utilization  matrices);  battle 
damage  probability  and  severity  data;  and  system  usage 
factors  data  (embedded  in  mission  data — assumptions  about 
sortie  rates,  durations,  and  frequencies,  by  type).  It 
should  be  noted  that  in  LCOM  version  4.1  (Richards,  1983) 
all  data  preparation  is  accomplished  off-line,  on  special 
formatting  forms,  and  is  then  translated  to  card  input  for 
database  development. 

2.  Preparation  time  for  one  run  of  the  model.  Depending  on 
the  scope  of  the  scenario  and  the  depth  to  which  the 
maintenance  system  is  simulated,  preparing  an  LCOM  database 
can  require  several  months.  One  available  estimate  is  10  - 
12  calendar  weeks  for  a  relatively  small-scale  simulation 
(Richards,  1983).  Each  calendar  week  probably  represents 
one  professional  staff-month  of  effort. 

3.  Execution  time  for  one  run  of  the  model.  Model  execution 
requires  several  Central  Processing  Unit  (CPU)  hours  on  a 
Control  Data  Corporation  mainframe  computer.  Execution 
time  is  variable,  and  increases  in  an  approximately  linear 
manner  with  the  number  of  conflict  "days"  simulated  and  the 
complexity  of  the  mission  scenario  defined  for  a  run. 
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4.  Level  of  effort  for  model  and  data  preparation.  Prepara¬ 
tion  of  an  LOOM  model  requires  several  person-months  of 
time  by  the  primary  analyst  team  (typical  is  six  to  eight 
person-months),  plus  consultation  time  from  logistics, 
mission  scenario,  and  maintenance  Subject  Matter  Experts 
(SMEs). 

5.  Model  capability  for  stochastic  and  event  modeling.  Both 
stochastic  and  event  modeling  are  supported  for  model 
nodes.  Several  types  of  standard  probability  distributions 
are  provided  by  the  support  software  for  stochastic 
simulation,  or  user-defined  distributions  and  parameters 
can  be  input  for  special  purposes. 

6.  Sensitivity  analysis  capability.  LOOM  can  support  sen¬ 
sitivity  analysis.  Sensitivity  analysis  is  accomplished  by 
providing  alternate  versions  of  input  data,  varying  on  the 
parameters  of  interest,  and  examining  the  differences  in 
output  parameters  that  result. 

7.  Sensitivity  analysis  effort  required.  A  large  amount  of 
effort  is  required  to  accomplish  sensitivity  analysis  using 
LCOM.  Since  each  point  on  a  sensitivity  curve  would 
require  an  entirely  separate  run  of  the  software,  the  level 
of  effort  increases  linearly  for  one  sensitivity  variable, 
and  by  the  cross-product  of  the  number  of  sensitivity  curve 
points  for  two  or  more  variables.  This  could  be  mitigated 
somewhat  by  using  common  data  for  non-manipulated  variables 
in  the  input  databases,  or  by  using  central-composite 
sampling  designs  rather  than  full-model  designs,  for 
sensitivity  analysis  explorations. 

8.  Ability  to  incorporate  or  manipulate  the  variables  of 
interest.  Most  of  the  major  variables  associated  with 
acquisition  policy,  manpower  and  personnel,  logistics,  and 
some  system  design  characteristics  could  theoretically  be 
accommodated  by  careful  development  of  an  LCOM  database. 
Many  of  the  specific  variables  would  have  to  manipulated 
indirectly  through  the  development  of  LCOM  task  networks 
and  other  input  data. 

9.  Phenomena  coverage  (domains).  Generally,  LCOM  appears  able 
to  deal  with  factors  related  to  acquisition  policy, 
manpower  and  personnel,  logistics,  and  some  system  design 
factors.  Variables  manipulated  with  respect  to  each  of 
these  would  have  to  be  carefully  defined  and  correlated  to 
characteristics  of  the  LCOM  database.  Acquisition  policy 
issues  could  be  dealt  with  by  varying  the  maintenance 
concept  and  maintenance  strategy  adopted  for  system 
support,  as  well  as  some  ultimate  task  variables  that  would 
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be  impacced  by  these  two  major  factors.  Manpower  and 
personnel  variables  could  be  manipulated  by  varying  task 
and  organizational  characteristics.  Logistical  variables' 
effects  could  be  explored  by  varying  capabilities  of  the 
logistical  support  system  such  as  spare  parts  availability, 
delay  time  characteristics,  or  task  characteristics  for 
maintenance  tasks.  System  design  factors  could  be  ad¬ 
dressed  through  varying  maintenance  task  demands  and 
characteristics. 

10.  Output  data  characteristics.  LOOM  provides  output  data 
that  deal  with  achieved  sortie  or  mission  generation, 
simulated  event  sequences  that  occurred  during  the  model 
run,  manpower  and  logistics  shortfalls  that  were  encounter¬ 
ed  (and  their  association  with  simulated  time  and  events), 
the  input  data  and  assumptions  used,  and  manpower  utiliza¬ 
tion  information  (Richards,  1983). 

11.  Availability.  LOOM  is  available  for  use,  and  can  be 
obtained  from  the  Air  Force  (ASD/ENESA)  on  request. 

Richards  (1983)  recommends  a  trained,  experienced  modeler 
and  logistician  make  up  a  part  of  the  LOOM  user  team. 

12.  Usage  cost  factors.  Four  major  use  cost  factors  will  be 
associated  with  using  LCOM.  They  are:  data  gathering  to 
develop  scenarios,  organizations,  and  other  needed  input; 
actual  development  of  the  database  for  LCOM  runs;  CPU  time 
expenditures;  and  time  required  for  output  interpretation 
and  developing  conclusions.  No  quantitative  values  can  be 
associated  with  the  use  of  LCOM  without  further  study.  It 
is  expected,  based  on  implications  from  LCOM  documentation 
(Richards,  1983),  that  a  total  level  of  effort  for  an  LCOM 
analysis  could  consume  as  much  as  3  -  4  person-years  of 
labor  and  as  much  as  several  hundred  CPU  hours. 


LCOM  Observations 


LCOM  has  a  great  deal  of  potential  for  use  in  exploring  optimized 
maintenance  concepts,  organizations,  and  strategies.  The  Air  Force 
requires  LCOM  be  used  to  model  and  estimate  the  manpower  and  availabil¬ 
ity  factors  associated  with  using  proposed  new  major  systems,  and 
continued  use  of  LCOM  to  re-assess  support ability  throughout  the  system 
life  cycle  (Air  Force  Regulation  25-8,  1978).  From  available  documen¬ 
tation,  LCOM  appears  to  be  quite  capable  of  dealing  with  most  of  the 
major  variables  that  might  be  addressed  in  maintenance  optimization 
efforts.  However,  the  large  level  of  effort  required  to  use  LCOM,  and 
the  amounts  of  data  and  CPU  time  needed  to  exercise  this  model,  suggest 
that  it  may  not  be  ideal  for  exploratory  analyses.  This  is 
particularly  true  if  a  single  system  exemplar  is  being  considered.  The 
Air  Force  reportedly  tends  to  use  LCOM  only  after  a  significant 
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commitment  to  a  new  system  has  been  made.  This  may  reflect  the  cost- 
benefit  associated  with  using  LOOM.  Also,  LCOM  would  require  a  large 
amount  of  adaptation  to  be  suitable  for  use  with  other  than  aviation 
systems.  For  Army  research  and  methods  development  purposes,  this  may 
represent  an  unacceptable  level  of  investment. 


OSAMM  Characteristics 


The  Optimum  Support  and  Maintenance  Model  (OSAMM)  is  described  by 
its  developers  (CECOM)  as: 

"...  designed  to  simultaneously  optimize  support  and 
maintenance  policies  for  new  equipment  while  achieving 
a  given  operationability  target  at  least  cost." 

(Department  of  the  Army,  1985) 

OSAMM  uses  input  data  available  early  in  the  system  acquisition 
process,  while  the  maintenance  concept  is  under  development.  It 
describes  organization  locales  for  Line  Replaceable  Unit  (LRU)  removal 
and  replacement;  parts  stockage  locations;  inventory  variables,  and 
manpower  and  Test,  Measurement,  and  Diagnostic  Equipment  (TMDE) 
requirements  (by  task).  Outputs  include  a  summary  of  the  maintenance 
policy  modeled,  achieved  system  operational  availability  (A^)  under  the 
maintenance  policy,  distributions  of  maintenance  and  replacement  tasks 
over  the  maintenance  organization  (by  task),  logistic  system  costs 
(based  on  input  assumptions),  and  the  relative  cost  of  each  maintenance 
concept  modeled.  OSAMM  is  also  capable  of  supporting  level  of  repair 
analyses  (LORA)  to  define  different  maintenance  concepts  and  philoso¬ 
phies.  It  is  not  clear  from  the  available  documentation  whether  this 
capability  is  achieved  by  sensitivity  analyses  in  a  single  execution  of 
the  model  or  whether  different  input  data  sets  are  required  to  examine 
alternative  candidates.  An  evaluation  of  OSAMM  (Department  of  the 
Army,  1985)  indicates  that  this  model  is  adequate  to  support  several 
subtasks  of  each  of  Logistical  Support  Analysis  (LSA)  tasks  203,  204, 
205,  302,  303,  and  501.  OSAMM  is  not  a  scenario-based  model  like  LCOM. 
It  is  described  as  a  linear  programming-based  optimization  model,  that 
operates  to  optimize  on  a  cost  basis. 

OSAMM  Characteristics  Summary 

The  data  given  below  expand  on  the  siimmary  data  on  OSAMM  provided 
in  Table  2. 


1.  Input  data  requirements.  OSAMM  requires  data  on  main¬ 
tenance  tasks  and  task  distributions  over  the  levels  of  the 
maintenance  system,  logistic  system  data  (including  parts 
identification  and  linkage  to  tasks,  logistic  delay  and 
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transport  time  assumptions,  manpower  and  parts  cost  data), 
organizational  assumptions  (TOE  and  manpower  distribu¬ 
tions),  system  use  rates  (to  derive  scheduled  maintenance 
frequencies),  and  maintenance  manpower  data  (by  task). 

2.  Preparation  time  for  one  run  of  the  model.  Several  months 
are  required  to  compile  data  and  prepare  for  an  execution 
of  OSAMM.  Estimates  from  CECOM  users  range  from  three 
months  for  a  relatively  uncomplicated  system,  to  over  six 
months  for  a  relatively  complex  system. 

3.  Execution  time  for  one  run  of  the  model.  Execution  time 
for  OSAMM  is  from  one  to  several  CPU  hours  on  the  mainframe 
computer  types  (IBM  and  CDC)  on  which  it  is  implemented. 

4.  Level  of  effort  for  model  and  data  preparation.  Discus¬ 
sions  with  OSAMM  users  at  CECOM  indicate  that  between  one- 
half  and  one  and  one-half  person-years  are  required  to 
prepare  an  OSAMM  model  for  use. 

5.  Model  capability  for  stochastic  and  event  modeling.  OSAMM 
can  accommodate  both  stochastic  and  deterministic  elements 
in  models  that  are  executed.  No  information  was  found  on 
the  manner  in  which  the  nature  of  particular  elements  is 
established  in  model  input.  The  OSAMM  program  itself  uses 
a  number  of  parameter-based  deterministic  algorithms.  It 
is  assumed  that  these  are  based  on  empirical  experience 
within  the  logistic  modeling  community. 

6.  Sensitivity  analysis  capability.  OSAMM  is  capable  of 
performing  sensitivity  analyses.  Sensitivity  analysis  is 
possible  during  a  single  run  for  certain  variables,  most 
notably  level  of  repair  analysis  and  maintenance  policy 
(the  OSAMM  software  generates  and  explores  alternate 
maintenance  policies  based  on  input  parameters).  Sen¬ 
sitivity  analysis  is  also  possible  by  using  alternate  data 
sets  or  models. 

7.  Sensitivity  analysis  effort  required.  For  variables  that 
can  be  explored  for  sensitivity  in  a  single  model  execu¬ 
tion,  sensitivity  analysis  effort  is  trivial.  The  level  of 
effort  required  to  develop  alternate  data  sets  for  sen¬ 
sitivity  analysis  on  other  variables  can  vary  widely, 
depending  on  the  amount  of  additional  data  that  must  be 
prepared.  Conversations  with  OSAMM  users  at  CECOM  indicate 
that  alternate  data  sets  are  seldom  used,  but  that  the 
effort  required  is  a  small  fraction  of  that  needed  to 
develop  an  original  OSAMM  data  set. 

8.  Ability  to  incorporate  or  manipulate  the  variables  of 
interest.  OSAMM  appears  to  be  able  accommodate  most  of  the 
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general  acquisition  related  variables  of  interest  in  the 
Evans  and  Roth  (1988)  conceptual  model,  with  the  exception 
of  manpower  and  personnel  variables.  These  appear  to  be 
manipulated  in  OSAMM  through  association  of  manpower  demand 
values  with  specific  tasks.  No  evidence  of  personnel 
variables  (e.g. ,  occupational  specialties,  skill  levels, 
etc.)  appears  in  the  documentation  examined  on  OSAMM. 

OSAMM  does  not  appear  to  be  able  to  accommodate  any  of  the 
compensatory  category  variables  that  reflect  reality  in 
maintenance  operations. 

9.  Phenomena  coverage  (domains).  OSAMM  appears  able  to  accom¬ 
modate  primarily  variables  associated  with  the  policy  and 
logistics  domains  in  the  Evans  and  Roth  (1988)  model. 

There  is  a  possibility  that  some  system  design  factors 
could  be  accommodated  indirectly,  through  manipulation  of 
the  characteristics  and  demands  of  maintenance  tasks 
provided  as  input  to  OSAMM. 

10.  Output  data  characteristics.  OSAMM  outputs  describe  the 
maintenance  policies  associated  with  the  maintenance  or¬ 
ganization  and  task  data  input,  achieved  availability  of 
the  modeled  system  given  input  data  assumptions,  task 
distributions  over  maintenance  levels  (i.e. ,  a  LORA 
analysis),  logistics  costs,  maintenance  concept  costs,  and 
a  summary  of  input  data  and  assumptions  used  in  a  model 
run.  Absolute  manpower  requirements  for  both  support  and 
maintenance  are  included  in  outputs. 

11.  Availability.  OSAMM  is  available  for  use,  since  it  is  a 
Government  developed  model.  It  is  available  in  IBM  and  CDC 
mainframe  versions.  Interactive  access  to  OSAMM  is 
reported  to  be  impossible  due  to  the  nature  of  the  software 
and  the  machine-specific  features  incorporated.  CECOM 
(AMSEL-PL-E)  is  the  custodian  of  OSAMM.  Assistance  in 
OSAMM  use  is  also  available  from  MRSA  (Mr.  Karenbauer, 
AMXMD-EL) . 

12.  Usage  cost  factors.  Cost  factors  in  using  OSAMM  include 
preparation  and  input  data  gathering  time,  runtime  costs, 
and  time  to  interpret  the  output  of  a  model  run  and  draw 
conclusions.  No  quantitative  estimates  of  the  cost  of 
conducting  an  OSAMM  analysis  are  available.  Based  on  the 
level  of  effort  for  model  data  preparation,  one  and  one- 
half  to  two  person-years'  equivalent  appears  realistic  for 
exercising  OSAMM. 
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OSAMM  Observations 


OSAMM  can  generally  be  considered  a  restricted-domain  model  that 
is  principally  used  for  the  exploration  of  and  attempts  at  optimizing 
maintenance  and  support  costs  for  a  system.  This  modeling  technique 
appears  to  have  less  overall  value  for  assessing  factors  that  impact 
maintenance  than  does  LOOM.  The  reason  for  this  observation  is  chat 
OSAMM  does  not  deal  with  manpower  and  personnel  variables  as  discrete 
elements,  other  chan  as  manpower  resource  requirements  associated  with 
maintenance  casks.  Personnel  characteristics  do  not  appear  to  be 
treated  at  all  in  OSAMM.  There  may  also  be  some  difficulty  in 
manipulating  variables  of  interest  to  general  maintenance  topics,  using 
OSAMM.  While  maintenance  policy  and  maintenance  concept  (two  important 
driver  factors  for  Che  maintenance  burden)  are  manipulable  in  OSAMM, 
and  Che  model  is  capable  of  LORA  analyses,  manpower  requirements 
associated  with  maintenance  Casks  must  be  provided  as  input  data. 

Since  OSAMM  is  principally  designed  Co  examine  logistic  cost  factors 
for  systems,  it  may  be  of  some  use  as  a  secondary  model  in  exploring 
maintenance  factors,  once  operational  factors  and  issues  have  been 
explored  by  other  means. 


LOGAM  Characteristics 


The  Logistics  Analysis  Model  (LOGAM)  is  characterized  as: 

"...[for]  evaluating  alternate  logistic  postures  for 
system  and  equipment  [items]  on  Che  basis  of  cost  and 
availability."  (Department  of  Che  Army,  198^) 

LOGAM  examines  maintenance  policies,  stockage  locations  for  spare 
parts,  test  equipment  capability,  and  manpower  mixtures  for  their 
combined  impact  on  system  availability  and  logistic  system  cost 
factors.  LOGAM  was  designed  for  use  in  early,  exploratory  LSA  inves¬ 
tigations  of  new  systems,  to  assist  in  determining  feasible,  cost- 
effective  approaches  to  logistic  support  for  new  systems.  This  model 
was  developed  by  the  U.S.  Army  Missile  Command  (MICOM),  and  has  been 
subsequently  used  by  MICOM  and  other  Army  commodity  commands  for  early 
logistic  ea^imation  for  a  number  of  systems.  LOGAM  is  reported 
(Department  of  Che  Army,  1984)  to  provide  data  that  support  various 
subtasks  of  LSA  casks  203,  204,  205,  302,  and  303.  Like  OSAMM,  LOGAM 
is  a  linear  programming-based  optimization  model,  rather  Chan  a 
scenario-based  model  such  as  LCOM.  Cost  is  used  as  Che  principal 
optimization  factor. 
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LOGAM  Characteristics  Summary 

LOGAM  characterise ics ,  expanding  on  the  summary  in  Table  2,  are  as 
follows : 

1.  Input  data  requirements.  Input  data  for  LOGAM  consist  of  a 
description  of  logistic-oriented  Tables  of  Organization  and 
Equipment  (TOE)  projected  to  support  the  system,  and  data 
associated  with  system  (LRUs),  including  failure  rates  and 
repair  times,  logistic  waiting  and  delay  times,  use  rates, 
and  associated  test  equipment  for  task  performance.  Also 
required  are  several  types  of  cost  data,  including  labor 
costs,  technical  documentation  costs,  and  transportation 
costs  (from  one  maintenance  level  to  another,  and  for  spare 
parts  transport). 

2.  Preparation  time  for  one  run  of  the  model.  Discussions 
with  MIC(M  users  of  LOGAM  indicate  that  three  to  six 
months'  calendar  time  is  typical  for  preparing  a  LOGAM 
model  and  data  set  for  execution. 

3.  Execution  time  for  one  run  of  the  model.  LOGAM  is  reported 
(Department  of  the  Army,  1985)  to  require  approximately  one 
to  five  minutes  of  CPU  time  to  execute  on  the  mainframe 
computers  on  which  it  is  implemented  (IBM  43XX  series  and 
CDC  6XXX  series). 

4.  Level  of  effort  for  model  and  data  preparation.  Approxi¬ 
mately  one  to  two  person-years'  level  of  effort  is  needed 
to  develop  a  LOGAM  model  and  input  data,  according  to 
conversations  with  MICOM  personnel. 

3.  Model  capability  for  stochastic  and  event  modeling.  LOGAM 
appears  to  be  able  to  accommodate  stochastic  events  or 
nodes,  but  explicit  use  of  stochastic  estimation  is  not 
reported  in  the  available  documentation  (Department  of  the 
Army,  1985).  Event  modeling,  based  on  the  linear  optimiza¬ 
tion  approach  used  in  LOGAM  development,  is  possible 
through  manipulation  of  time  parameters  and  failure  rates. 

6.  Sensitivity  analysis  capability.  Sensitivity  analysis  is 
possible  with  LOGAM,  through  the  use  of  alternate  input 
data  sets.  In  general,  LOGAM  will  develop  a  cost-optimized 
output  solution  based  on  input  data.  Thus,  sensitivity 
analysis  within  one  run  of  the  model  is  not  considered 
possib  le . 

7.  Sensitivity  analysis  effort  rc^quired.  Since  alternate 
input  data  sets  are  required  for  sensitivity  analysis  with 
LOGAM,  the  level  of  effort  associated  should  vary  ap- 


21 


proximately  linearly  with  the  number  of  sensitivity  points 
explored  in  an  analysis.  However,  generation  of  a  total 
data  set  is  not  required  for  each  sensitivity  point  to  be 
explored.  Deviations  from  a  baseline  data  set  accommodate 
many  sensitivity  analysis  requirements. 

8.  Ability  to  incorporate  or  manipulate  the  variables  of 
interest.  LOGAM  appears  to  be  restricted  somewhat  in  its 
ability  to  accommodate  variables  described  in  the  Evans  and 
Roth  (1988)  conceptual  model.  LOGAM  should  have  some 
sensitivity  to  some  policy  issues  (levels  of  repair,  task 
allocation,  maintenance  strategy  and  concept,  and  force 
structure).  It  should  also  be  sensitive  to  manpower  demand 
(by  task)  and  design  issues  (repair  times),  as  well  as  use 
rates.  General  MPT  issues,  and  some  design  issues, 
probably  are  not  suitable  for  exploration  using  LOGAM. 

9.  Phenomena  coverage  (domains).  In  general,  LOGAM  should  be 
usable  to  explore  policy  issues,  manpower  demands,  and  some 
design  issues,  as  well  as  logistics  issues.  Since  LOGAM' s 
approach  centers  around  exploration  of  the  demand  as¬ 
sociated  with  various  LRUs,  there  may  be  some  value  in 
exploring  impacts  of  "high  dr iver"-associated  equipment 
items  or  LRUs  on  maintenance  demand  and  associated  costs. 

10.  Output  data  characteristics.  LOGAM  provides  the  following 
categories  of  output:  operational  and  inherent  availabil¬ 
ity  (Aq  and  Ai)  of  each  LRU  in  the  system;  maintenance 
support  demand  (manhours);  operations  support  demand  (also 
by  manhours);  and  a  support  requirements  summary  for  each 
LRU  in  the  system.  Aggregated  summaries  are  also  provided 
above  the  LRU  level. 

11.  Availability.  LOGAM  is  Army-developed  and  owned,  and  is 
therefore  available  for  potential  use.  It  can  only  be 
accessed  interactively,  however.  Also,  the  computer 
programs  presently  require  large-scale  mainframe  computer 
support.  MICOM  (Systems  Analysis  Directorate,  DRSMI-DS)  is 
the  custodian  and  maintainer  of  LOGAM.  Assistance  in  LOGAM 
use  is  also  available  from  MRSA  (Mr.  Atkinson,  AMXMD-EL) . 

12.  Usage  cost  factors.  Using  LOGAM  requires  investment  in 
data  and  preparation  time,  and  interpretation  of  model 
output.  Given  the  relatively  small  amount  of  CPU  time 
required  for  LOGAM  runs,  this  is  not  considered  to  be  a 
major  factor. 
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LCX5AM  Observations 


Since  LOGAM,  like  OSAMM,  is  a  restricted  linear  optimization 
approach  to  examining  system  support  requirements,  it  appears  less 
suitable  for  programmatic  exploration  of  factors  impacting  maintenance 
than  a  scenario-based  model.  Some  of  LOGAM' s  limitations  include  an 
inability  to  deal  with  personnel  factors  (occupational  specialties  and 
skill  levels),  and  an  orientation  toward  micro,  rather  than  macro, 
system  elements  (e.g.  ,  concentration  on  LRUs  as  the  element  of  anal¬ 
ysis).  While  LOGAM's  data  requirements  and  computational  time  require¬ 
ments  are  modest  compared  to  some  models,  its  suitability  for  exploring 
the  total  range  of  issues  in  the  Evans  and  Roth  (1988)  model  is 
restricted.  LOGAM  appears  to  one  of  the  less  suitable  estimation 
approaches  examined  for  supporting  exploratory  work  in  maintenance 
system  optimization. 


MARC  Models  Characteristics 


Three  models  to  support  the  Manpower  Requirements  Criteria  (MARC; 
Army  Regulation  570-2)  development  process  are  under  development  by  the 
Army  Logistics  Center  (LOGC).  The  models  are  specific  to  unit  equip¬ 
ment  types:  aviation,  tracked  vehicle,  and  wheeled  vehicle  models  are 
being  developed.  Of  the  three  models,  only  the  aviation  model  is 
currently  operational.  The  tracked  vehicle  model  is  scheduled  to  be 
available  for  use  sometime  in  the  next  calendar  year.  The  wheeled 
vehicle  model  is  under  development,  with  no  projected  availability  date 
as  of  March,  1988.  All  characteristics  reported  below  are  therefore 
based  on  the  known  attributes  of  the  aviation  MARC  model.  Data 
reported  below  are  based  on  an  interview  with  LOGC  personnel  conducted 
on  8  February  1988  (Fisher,  1988;  Blair,  1988;  Price,  1988). 

The  aviation  MARC  model  is  a  scenario-driven  model  with  many 
functional  similarities  to  LCOM.  This  model  portrays  a  brigade  and 
associated  unit  support  "slice"  up  through  the  Corps  level.  Of 
particular  note  in  this  model  is  the  attention  devoted  to  modeling  the 
maintenance  process.  Detailed  operational  maintenance  models,  that  use 
realistic  derived  criteria,  are  used  in  "playing  out"  the  scenarios 
specified  for  the  model.  This  represents  a  potentially  valuable 
approach  to  exploring  organizational,  manpower,  and  personnel  aspects 
of  maintenance.  However  (see  below),  the  aviation  MARC  model  uses 
large  amounts  of  resources  in  its  execution.  This  may  represent  a 
significant  tradeoff  factor  if  this  model  is  further  considered  for 
use . 


Aviation  MARC  Model  Characteristics  Summary 

The  following  data  expands  on  the  Aviation  MARC  model  summary 
presented  in  Table  2. 
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1.  Input  data  requirements.  This  model  requires  several 
classes  of  data  as  input,  including;  available  resources 
(number  of  personnel,  number  of  systems,  and  spare  parts 
amounts  and  locations):  predicted  equipment  failure  rates 
for  all  systems  and  support  equipment  to  be  modeled; 
desired  readiness  rates  for  systems;  threat  and  weapons- 
effects  models;  spare  parts  availability  factors;  indirect 
productivity  fa^^ora  for  maintenance;  equipment  usage 
rates;  organizational  structure  supporting  the  systems 
(i.e.,  how  the  unit  and  support  "slice"  are  organized);  and 
the  mission  scenario  to  be  played  out  (including  sortie 
rates  and  equipment  criteria  for  sorties,  etc.).  Data  are 
derived  from  a  number  of  Army  sources,  including  MRSA,  the 
Ballistics  Research  Laboratory  (BRL),  Training  and  Doctrine 
Command  (TRADOC)  schools;  Army  Materiel  Command  (AMC) 
laboratories,  and  dat<i  maintained  by  LOGC.  Maintenance 
task  data  are  provided  by  estimates  from  prior  systems 
(e.g.,  a  Baseline  Comparison  System  or  BCS),  and  validated 
by  SMEs.  Most  data  are  provided  on  magnetic  tape,  in 
formats  established  by  Headquarters  AMC,  in  cooperation 
with  other  agencies  that  supply  data  to  LOGC  for  the 
analyses . 

2.  Preparation  time  for  one  run  of  the  model.  Data  collec¬ 
tion,  preparation,  and  validation  requires  several  months 
for  the  Aviation  MARC  model  (Price,  1988). 

3.  Execution  time  for  one  run  of  the  model.  For  a  simple 
case,  the  Aviation  MARC  model  requires  up  to  eight  (8) 
hours  of  dedicated  CPU  time  on  a  Digital  Equipment 
Corporation  (DEC)  VAX  11/785  minicomputer.  Complex  cases 
are  reported  (Price,  1988)  to  require  up  to  40  dedicated 
CPU  hours  for  execution. 

A.  Level  of  effort  for  model  and  data  preparation.  No  direct 
information  was  available  via  the  LOGC  interviews  to 
address  this  issue.  It  is  projected  that,  given  the  number 
of  involved  agencies  and  the  time  required  for  data 
preparation,  that  between  one-half  and  one  and  one-half 
person-years  is  a  reasonable  estimate  for  the  level  of 
effort  required. 

5.  Model  capability  for  stochastic  and  event  modeling.  The 
Aviation  MARC  model  can  handle  both  stochastic  and  event 
modeling.  Both  types  of  representation  are  routinely  used 
in  various  parts  of  the  model. 

6.  Sensitivity  analysis  capability.  The  Aviation  MARC  model 
is  capable  of  sensitivity  analysis.  Some  parameters  can  be 
manipulated  within  a  single  model  execution  (specifics  were 
not  determined  during  the  interviews);  other  parameters 
must  be  manipulated  for  sensitivity  analysis  purposes  by 
altering  the  input  data  sets  and  re-executing  the  model. 


24 


7.  Sensitivity  analysis  effort  required.  For  those  parameters 
that  can  be  manipulated  during  a  single  model  execution, 
the  effort  associated  with  sensitivity  analysis  is  almost 
totally  associated  with  designing  the  sensitivity  analysis 
model  and  interpreting  outputs  from  model  execution.  Thus, 
the  level  of  effort  will  be  relatively  small  compared  with 
the  overall  cost  of  using  this  model.  For  parameters  that 
require  alteration  of  input  data  sets  to  achieve  sen¬ 
sitivity  analysis,  significantly  more  effort  will  be 
required.  Even  a  close  estimate  of  the  level  of  effort  for 
this  process  is  unavailable,  since  there  has  been  relative¬ 
ly  little  experience  with  performing  sensitivity  analysis 
in  this  fashion  using  the  Aviation  MARC  model  (Price, 

1988). 

8.  Ability  to  incorporate  or  manipulate  the  variables  of 
interest.  While  limited  to  consideration  of  units  operat¬ 
ing  primarily  aviation  systems,  the  Aviation  MARC  model 
appears  to  be  able  to  accommodate  essentially  all  of  the 
acquisition-related  issues  described  in  the  Evans  and  Roth 
(1988)  conceptual  model.  The  issues  associated  with 
maintenance  operations  (particularly  compensatory  issues) 
in  Evans  and  Roth  (1988)  probably  cannot  be  dealt  with  by 
this  model. 

9.  Phenomena  coverage  (domains).  Most  issues  in  each  of  the 
domains  described  in  the  Evans  and  Roth  (1988)  conceptual 
model  of  maintenance  demand  factors  (limited  to  acquisition 
issues)  can  be  handled  by  the  Aviation  MARC  model. 

10.  Output  data  characteristics.  The  principal  output  of  the 
Aviation  MARC  model  is  the  system  operational  availability 
(Aq)  associated  with  the  input  data  set  and  scenario. 
Supplementary  outputs  include  a  detailed  event  summary, 
manpower  utilization  and  requirements  by  MOS,  maintenance 
task  performance  by  level  of  maintenance,  sortie  rates 
achieved  (and  equipment  profile  by  sortie),  spare  parts 
demand  and  use  rates,  accumulated  logistic  and  maintenance 
delays,  and  operational  and  support  performance  summaries. 

11.  Availability.  The  Aviation  MARC  model  is  Army-developed 
and  -owned,  and  is  therefore  available  for  use.  Its 
proponent  and  maintainer  is  LOGC.  The  model  cannot  be 
accessed  by  remote  means. 

12.  Usage  cost  factors.  Usage  cost  factors  associated  with  the 
Aviation  MARC  model  include  specification  of  data  require¬ 
ments  and  scenario  characteristics,  data  preparation  and 
data  gathering,  CPU  time,  and  interpretation  of  outputs. 
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MARC  Models  Observations 


The  Aviation  MARC  model,  and  in  concept  the  two  developmental  MARC 
models,  is  an  extremely  powerful  means  of  examining  the  consequences  of 
a  given  support  and  maintenance  organization  on  mission  readiness  and 
capability.  Based  on  the  available  information,  it  appears  that  this 
model  is  at  least  hypothetically  capable  of  dealing  with  the  majority 
of  significant  acquisition-related  maintenance  issues  of  potential 
interest  to  ARI.  There  are  three  present  arguments  that  suggest  that 
this  model  not  be  used  for  exploratory  research,  however.  The  first  is 
the  amount  and  variety  of  data  required  to  prepare  a  data  set  for 
execution  against  the  model  software.  The  efforts  of  several  different 
agencies  (and  associated  Memoranda  of  Agreement,  etc.)  are  required  to 
develop  a  data  set  for  the  MARC  models.  This  could  prove  a  significant 
deterrent  to  the  use  of  this  model,  since  large  amounts  of  time  and 
resources  are  required  to  gather  and  validate  input  data.  A  second, 
rather  obvious,  problem  is  that  the  only  one  of  the  MARC  models 
available  for  current  use  is  limited  to  aviation  systems  and  units. 
Since  the  Army  has  only  one  major  aviation-related  system  under 
consideration  (the  Light  Helicopter,  LHX),  this  may  be  more  limiting 
for  research  purposes  than  is  desirable.  Finally,  this  model  requires 
a  very  large  amount  of  dedicated  CPU  time  to  execute.  In  a  complex 
model  case  with  any  significant  degree  of  sensitivity  analysis  being 
performed,  using  this  model  could  occupy  a  major  computing  resource 
exclusively  for  several  days.  Unless  such  a  resource  were  to  be  made 
available,  this  model  would  probably  prove  unsuitable  for  ARI's 
immediate  purposes. 


HARDMAN  II  (MIST)  Characteristics 


HARDMAN  II  (formerly  known  as  Man  Integrated  Systems  Technology, 
or  MIST)  is  a  computer  support  system  developed  by  ARI  in  the  mid- 
1980's  in  an  attempt  to  simplify  and  rationalize  a  significant  portion 
of  the  data  maintenance,  and  some  analytic,  functions  associated  with 
conducting  HARDMAN  (HARDware  versus  MANpower)  analyses.  The  HARDMAN 
technique,  adapted  for  Army  use  (Mannle  and  Guptill,  1983),  provides  a 
structured  approach  to  developing  BCS  and  conducting  exploratory 
analyses  of  probable  MPT  characteristics  for  new  systems  very  early  in 
the  acquisition  process.  Since  there  are  a  great  many  redundant  data 
elements  in  the  documentation  that  results  from  a  HARDMAN  application, 
HARDMAN  II  provides  a  database  system  that,  in  essence,  rationalizes 
data  utilization  resulting  from  HARDMAN  analysis,  and  ensures 
consistent  utilization  of  data  across  the  various  forms  of 
documentation.  HARDMAN  II  also  provides  some  analytic  aiding  to  the 
HARDMAN  analyst,  in  the  form  of  databases  for  consultation  (principally 
for  MOS  decisions,  some  personnel  pipeline  determinations,  and  training 
cost  estimation  and  media  selection),  decision  guidance,  and  suggested 
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decision  criteria.  However,  most  of  the  decisions  required  of  the 
analyst  in  the  HARDMAN  process  must  be  made  off-line  when  using  HARDMAN 
II. 


Although  it  is  not  a  modeling  approach  per  se ,  HARDMAN  II  was 
included  in  this  analysis  because  of  a  demonstrated  utility  in  explor¬ 
ing  some  aspects  of  maintenance  demand  factors.  Recent  work  by  Shvem 
and  Stewart  (1988)  and  Stewart  and  Shvern  (1988)  utilized  HARDMAN  II  in 
exploratory  investigations  of  some  maintenance  manpower  requirements 
related  to  two  components  of  the  Forward  Area  Air  Defense  (FAAD)  system 
under  development,  with  significant  success.  While  development  of  a 
HARDMAN  consolidated  database  and  performing  appropriate  Front-End 
Analyses  (FEA)  is  known  to  be  a  time-consuming  and  laborious  process, 
it  is  presently  the  principal  means  of  early  exploration  of  MPT 
characteristics  of  proposed  new  systems  within  MANPRINT.  Therefore, 
HARDMAN  II  was  examined  on  the  same  basis  as  the  other  estimation 
approaches,  to  determine  its  relative  utility.  An  additional  reason 
for  examining  HARDMAN  II  is  that  it  is  an  ARI-maintained  asset,  and 
thus  readily  available  for  use  in  future  investigations. 


HARDMAN  II  Characteristics  Summary 

The  following  information  elaborates  on  the  characteristics  of 
HARDMAN  1 1  as  summarized  in  Table  2. 

1.  Input  data  requirements.  Input  data  requirements  for 
HARDMAN  II  are  based  on  the  results  of  conduct  of  the 
HARDMAN  FEA  methodology.  A  full  listing  of  the  data 
elements  input  into  HARDMAN  II  may  be  found  in  Herlihy,  et . 
al .  (1985).  The  categories  of  data  include  system  require¬ 
ments  analysis  data,  mission  analysis  data,  functional 
requirements  and  engineering  analysis  data,  manpower  and 
reliability  and  maintainability  determinations,  personnel 
analysis  results,  training  analysis  results,  MOS  selections 
and  determinations,  manpower  determinations,  personnel 
determinations,  and  training  resource  and  cost  determina- 

t ions . 

2.  Preparation  time  for  one  run  of  the  model.  Approximately 

10  months  (Shvern  and  Stewart,  1988)  is  required  to  develop 
a  HARDMAN  II  consolidated  database,  including  performing 
the  requisite  HARDMAN  analyses  in  conjunction  with  HARDMAN 

11  support. 

3.  Execution  time  for  one  run  of  the  model.  Execution  time 
equates  to  preparation  time,  since  preparation  time 
includes  all  off-line  analyses.  No  modeling  is  conducted 
by  HARDMAN  II. 

4.  Level  of  effort  for  model  and  data  preparation.  Anecdotal¬ 
ly,  a  HARDMAN  II  analysis  with  development  of  a  full 
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consolidated  database  is  reported  to  require  approximately 
two  person-years  of  effort  as  a  typical  figure. 

5.  Model  capability  for  stochastic  and  event  modeling.  None. 
No  modeling  is  accomplished  in  HARDMAN  II. 

6.  Sensitivity  analysis  capability.  Sensitivity  analysis  is 
possible  with  HARDMAN  II,  by  altering  the  assumptions  used 
and  determinations  made  as  part  of  the  HARDMAN  process. 

The  capability  to  explore  alternate  consequences  of 
automated  test  equipment  capability  on  manpower  require¬ 
ments  using  HARDMAN  II  was  demonstrated  by  Shvern  and 
Stewart  (1988)  and  Stewart  and  Shvern  (1988).  Hypotheti¬ 
cally,  other  types  of  sensitivity  analysis  can  be  performed 
by  knowledgeable  users  of  HARDMAN  II. 

7.  Sensitivity  analysis  effort  required.  Using  a  full  data 
set,  HARDMAN  II  has  required  on  the  order  of  15  person- 
months  (in  about  six  calendar  months)  to  accomplish  a 
sensitivity  analysis  (Stewart  and  Shvern,  1988).  Using  a 
more  restricted  data  set,  approximately  four  person-months 
(in  two  calendar  months)  were  required  for  a  related 
sensitivity  analysis  effort  (Shvern  and  Stewart,  1988). 

8.  Ability  to  incorporate  or  manipulate  the  variables  of 
interest.  HARDMAN  II  is  potentially  able  to  deal  with  most 
acquisition-related  policy  and  MPT  issues  in  the  Evans  and 
Roth  (1988)  conceptual  maintenance  demands  model.  It  also 
has  a  demonstrated  ability  to  deal  with  at  least  some  of 
the  design  issues.  However,  HARDMAN  II  probably  cannot 
deal  with  logistics-related  acquisition  issues.  It  also 
appears  unable  to  deal  with  any  of  the  operational  issues 
in  the  Evans  and  Roth  (1988)  conceptual  model,  since  no 
process  modeling  can  be  performed  in  HARDMAN  II. 

9.  Phenomena  coverage  (domains).  As  mentioned  above,  three  of 
the  four  acquisition-related  domains  are  potentially 
addressable  through  HARDMAN  analyses  and  HARDMAN  II 
support:  policy,  MPT,  and  design. 

10.  Output  data  characteristics.  HARDMAN  II  output  data  are 
presented  as  any  of  a  variety  of  formatted  reports  sum¬ 
marizing  input  data  and  determinations  made  by  the  HARDMAN 
analysts.  Some  aggregation  and  summarization  of  FEA  and 
MPT  data  items  is  made  for  these  reports,  to  render  them 
useful  for  various  classes  of  users  and  different  purposes. 

11.  Availability.  HARDMAN  II  is  maintained  by  ARI,  and  is 
available  for  use  in  future  investigations  of  maintenance, 
within  the  domain  and  variable  coverage  limitations 
described  above. 
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12.  Usage  cost  factors.  The  cost  of  using  HARDMAN  II  is 
basically  driven  by  database  development  and  output 
interpretation.  No  "modeling"  CPU  costs  are  involved, 
although  some  costs  will  be  associated  with  using  the 
HARDMAN  II  software,  and  computer  system  resource  use 
charges  will  be  encountered.  These  should  be  relatively 
minor  compared  to  the  costs  of  data  development. 


HARDMAN  II  Observations 


HARDMAN  II  appears  to  have  significant  potential  for  exploring 
acquisition-related  issues,  particularly  in  investigating  the  impact  of 
policy  and  design  issues  on  manpower  demand  factors.  It  is,  however,  a 
laborious  and  somewhat  cumbersome  technique  to  use  for  these  purposes. 
Experienced  HARDMAN  II  users  should  participate  heavily  in  planning 
future  utilization  of  HARDMAN  II  for  exploratory  research. 

The  development  of  HARDMAN  II  databases  solely  for  research 
purposes  may  not  be  a  cost-effective  approach  to  exploring  maintenance 
impacts  within  the  MANPRINT  context.  However,  the  use  of  sensitivity 
analysis  on  existing  HARDMAN  II  databases  would  be  a  much  more  par¬ 
simonious  approach.  This  capability  has  been  demonstrated  by  Shvem 
and  Stewart  (1988)  and  Stewart  and  Shvern  (1988).  Again,  experienced 
HARDMAN  II  users  should  play  a  major  role  in  planning  such  investiga¬ 
tions,  since  appropriate  selection  of  the  input  parameters  to  be 
altered  in  sensitivity  analysis  will  have  a  profound  impact  on  the 
value  of  the  results. 


Reduced-Scale  Modeling  Approaches 


One  common  characteristic  of  the  five  approaches  just  reviewed  is 
that  they  all  require  large-scale  computational  resources  and  large 
amounts  of  highly  specific  input  data  in  order  to  support  their 
respective  estimation  procedures.  From  a  MANPRINT-oriented  exploratory 
research  standpoint,  the  use  of  such  resource-intensive  tools  is  less 
than  ideal.  While  use  of  such  large-scale  tools  may  contribute  to  an 
understanding  of  the  manner  in  <^ich  maintenance  demand-influencing 
factors  operate  and,  ultimately,  to  principles  and  techniques  to 
minimize  the  maintenance  burdens  of  new  systems,  the  costs  of  using 
such  tools  may  be  prohibitive. 

In  the  last  two  years,  at  least  one  significant  smal ler-scale  tool 
for  conducting  modeling  investigations  of  task-type  processes  has 
emerged.  This  tool  is  MicroSAINT(TM) .  MicroSAINT(TM)  has  the  ad¬ 
vantage,  for  exploratory  purposes,  of  executing  on  personal  computer 
systems,  which  are  generally  able  to  be  dedicated  to  such 
investigations.  Also,  MicroSAINT(TM)  can  represent  a  task  performance 
model,  such  as  developed  for  maintenance  by  Evans  and  Roth  (1988), 
quite  adequately.  Further,  MicroSAINT(TM)-based  models  can,  when 
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properly  developed,  account  for  resource  demands  and  expenditures  of 
the  kinds  that  are  associated  with  maintenance  performance  (e.g.  , 
personnel  and  manpower,  spare  parts,  etc.). 

What  is  envisioned  is  the  development  of  one  or  more  models  of 
maintenance  process  systems,  including  the  capability  to  track  resource 
demand,  availability,  and  use.  Such  models  could  represent  alternate 
maintenance  systems  for  an  operational  materiel  system  based  on  various 
maintenance  strategies,  philosophies,  or  organizational  concepts,  and 
reacting  to  varying  levels  of  demand  factors.  Specific  maintenance 
tasks  and  conditions  under  which  each  task  is  performed  would  be 
represented  in  the  models,  and  the  resources  required  to  accomplish 
each  task  would  be  specified  in  terms  of  manpower,  personnel,  and  other 
resources.  An  LCOM-like,  iterative,  approach  to  exercising  the  model 
over  many  time  periods  would  be  used,  examining  maintenance  system 
performance  and  demand  factors  on  a  periodic  basis. 

This  approach  has  several  advantages  over  use  of  existing  large- 
scale  models.  First,  system  operations  (that  lead  to  maintenance 
needs)  need  not  be  explicitly  modeled.  These  factors  can  be  represen¬ 
ted  by  parameters  describing  maintenance  task  performance  frequency. 

For  example,  scheduled  and  unscheduled  maintenance  demands  by  par¬ 
ticular  task  type,  or  battle  damage  (based  on  some  probabilistic 
function)  can  be  represented  as  either  periodic,  scheduled,  or  probabi¬ 
listic  events.  The  LSA  process  and  other  FEA  techniques  commonly 
describe  many  types  of  maintenance  tasks  on  a  task  requirement  per 
operating  hour  (or  other  operational  parameter)  basis,  or  on  a  frequen¬ 
cy  ()^  occurrences  of  the  task  per  day,  week,  month,  etc.)  basis.  Thus, 
data  descriptive  of  raw  maintenance  demands  for  systems  will  be 
compatible  with  their  representation  in  such  models. 

Second,  the  operational  nodes  in  the  maintenance  system  can  be 
represented  as  queues,  against  which  task  performance  demands  accumu¬ 
late  as  maintenance  tasks  are  scheduled.  This  enables  both  monitoring 
of  resource  demand  and  consumption  (e.g.,  personnel,  spare  parts,  etc.) 
by  particular  activity  nodes  (e.g.,  diagnosis  of  faults,  particular 
types  of  repair  actions)  and  tracking  of  total  resource  demand  during 
each  cycle  of  execution.  In  turn,  tracking  resource  demand  and 
consumption  enables  pinpointing  over-demand  for  particular  resources. 
This  can  be  particularly  important  in  identifying  where  there  are 
suspected  bottlenecks,  or  high  demand  drivers,  in  a  system.  In  some 
cases,  modifying  or  eliminating  such  high  demand  drivers  can  lead  to 
measurable  improvement  in  the  performance  of  a  system. 

Third,  this  modeling  approach  supports  continuous  monitoring  of 
maintenance  system  output,  and  related  but  derived  variables  such  as 
mission  capability  or  availability  of  the  "fleet"  of  systems  to  be 
maintained.  Since  maintenance  is  an  operations  support  activity,  this 
is  an  extremely  important  parameter  to  be  monitored.  Operations  cannot 
sue  eed  if  sufficient  systems  are  not  available. 

Finally,  this  approach  supports  a  parsimonious  representation  of 
any  maintenance  concept  and  maintenance  strategy,  over  all  levels  of 
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maintenance.  Each  level  of  maintenance  can  be  modeled  separately,  as  a 
sub-model,  and  the  relationships  and  flows  between  them  easily  defined, 
in  such  a  model.  And,  the  performance  of  each  level  of  maintenance  can 
be  monitored  both  individually  and  in  the  aggregate.  Within  the  type 
of  model  envisioned,  any  organizational  structure  that  can  be  defined 
by  TOE  can  theoretically  be  accommodated. 

Such  an  approach  is  projected  to  be  highly  valuable  in  exploratory 
investigations  of  maintenance  strategies  and  concepts  for  both  existing 
and  new  systems.  Since  relatively  few  resources  would  be  required  to 
develop  and  execute  such  models,  sensitivity  analysis  of  alternate 
maintenance  resource  configurations  (e.g.  ,  personnel;  manpower  avail¬ 
ability)  and  assessment  of  the  performance  of  many  alternate  candidate 
maintenance  structures  for  projected  new  systems  would  be  simple  and 
straightforward.  And,  model  outputs  could  be  developed  to  be  easily 
understandable  by  decision-makers,  reflecting  tradeoffs  between 
alternate  maintenance  resource  configurations  and  systems  availability. 

Since  models  based  on  such  an  approach  are  not  yet  generally 
available,  no  evaluation  against  the  12  factors  discussed  for  other 
modeling  approaches  above  is  made.  However,  it  is  projected  that  the 
desirable  features  on  each  factor  described  in  the  previous  section 
could  be  satisfied  by  the  general  modeling  approach  described. 
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CONCLUSIONS 


Of  Che  six  modeling  approaches  discussed  in  Che  previous  secCion, 
four  have  characCerisC ics  ChaC  are  desirable  Co  supporC  exploraCory 
research  inCo  minimizacion  of  Che  mainCenance  burden  (LCCM,  Aviacion 
MARC,  HARDMAN  II,  and  Che  reduced-scale  modeling  approach).  OSAMM  and 
LOGAM,  because  Chey  have  been  developed  co  opcimize  on  specific 
variables,  are  less  desirable  from  an  exploraCory  sCandpoinC.  While 
Chese  models  are  perfecCly  adequace  for  Che  purposes  and  in  Che  domains 
for  which  Chey  have  been  developed  (DeparCmenc  of  Che  Army,  1984, 

1983),  chey  are  less  well  suiced  for  a  programmaCic  exploracion  of  Che 
impacc  of  individual  variables  on  mainCenance  demand.  In  parcicular, 
Chese  models  seek  Co  opCimize  Che  values  of  all  imporcanc  variables 
(wich  cose  as  Che  principal  opcimizacion  criCerion)  for  a  parcicular 
inpuC  daCa  case,  racher  Chan  a  more  deliberaCe  conCrolled  exploracion 
of  Che  individual  and  joinC  influences  of  specific  variables  on  Che 
mainCenance  burden  and  relaCed  resources.  Ic  is  Che  laCCer  sorC  of 
approach  which  is  believed  Co  have  Che  mosc  value  in  developing  mechods 
and  Cechniques  Co  supporC  Che  implemencacion  of  MANPRINT  wich  regard  Co 
Che  mainCenance  funeCion. 

Among  Che  four  modeling  approaches  wich  parCicularly  desirable 
general  characCeriscics,  sensicivicy  analysis  wich  HARDMAN  II  and  Che 
reduced-scale  modeling  approach  offer  Che  mosC  parsimonious  approaches 
Co  supporC ing  programmaCic  research  inco  minimizing  Che  mainCenance 
burden  and  relaced  resource  demands.  AlChough  LOOM  and  Che  MARC  models 
can  concepCually  supporC  such  exploracions,  Che  use  of  Chese  models  is 
cime-  and  resource-inCens ive .  A  relaced  shorCcoming  of  boCh  chese 
models  for  general  research  purposes  is  ChaC  Chey  are  rescricced  by 
Cheir  nacure  Co  exploracions  involving  aviaCion  sysCems.  Also,  Che 
amounCs  of  daCa  required  Co  exercise  Chese  models  could  lead  Co  some 
confusion  as  Co  whaC  Co  manipulaCe  in  Che  inpuC  daCa  Co  bring  abouC  a 
change  in  some  paramecer  believed  Co  influence  Che  mainCenance  burden. 

A  good  deal  of  familiaricy  wich  HARDMAN  II  is  apparenCly  required 
CO  perform  effeccive  sensicivicy  analyses.  Also,  Che  level  of  efforc 
required  in  analyses  Co  develop  new  dacabases  for  HARDMAN  II  is  quice 
high.  Therefore,  ic  is  recommended  ChaC  Che  developmenC  of  a  reduced- 
scale  modeling  approach  for  exploring  Che  influences  of  Che  variables 
in  Che  Evans  and  RoCh  (1988)  concepCual  model  be  pursued  as  Che  firsc 
sCep  in  fuCure  mainCenance  research  by  ARI.  Two  person-years  of  efforC 
is  esCimaCed  Co  be  adequaCe  for  Che  inicial  developmenC  and  evaluacion 
of  such  a  model,  using  MicroSAINT(TM)  as  a  developmenC  cool.  This 
would  include  developmenC  of  a  base-case  mainCenance  syscem  model. 
ConcurrenC  wich  inicial  developmenC  of  Che  model,  sensicivicy  analyses 
using  HARDMAN  II  could  be  pursued  Co  reduce  Che  inicial  variable  sec  Co 
be  explored. 
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APPENDIX  A 


AFHRL 

AHC 

ARI 

BCS 

BRL 

CECOM 

FAAD 

FEA 

HARDMAN 

HARDMAN 

LCOM 

LOGAM 

LOGC 

LORA 

LRU 

MANCAP 

MARC 

MICOM 

MIST 

MOS 

MPT 

MRSA 


LIST  OF  ABBREVIATIONS  AND  ACRONYMS 

Air  Force  Human  Resources  Laboratory 
U.S.  Army  Materiel  Command 

U.S.  Army  Research  Institute  for  the  Behavioral  and 
Social  Sciences 

Baseline  Comparison  System(s} 

U.S.  Army  Ballistics  Research  Laboratory 

U.S.  Communlca tlons-Elec tronlcs  Command 

Forward  Area  Air  Defense 

Front'-End  Analyses 

HARDware  versus  MANpower  Analysis 

II  A  computer  support  system  for  HARDMAN  analysis 

Logistics  Composite  Model 

Logistics  Analysis  Model 

U.S.  Army  Logistics  Center 

Level  of  Repair  Analysis 

Lowest  Replaceable  Unit 

MANpower  CAPablllty  Model 

MAnpower  Requirements  Criteria 

U.S.  Army  Missile  Command 

Man  Integrated  Systems  Technology 

Military  Occupational  Special ty( les) 

Manpower,  Personnel,  and  Training 

U.S.  Army  Materiel  Readlnesa  Support  Activity 
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OSAMM 

SNE(«) 

TRADOC 


Optimum  Supply  and  Maintenance  Model 
Subject  Matter  Expert(8) 

D.S.  Army  Training  and  Doctrine  Command 
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